从病毒到“基础软件污染”，Linux 真的安全吗？

查看原文

其他

从病毒到“基础软件污染”，Linux 真的安全吗？

Original 王福维、程聪 CSDN 2020-12-18

作者 | 阿里云安全专家王福维(弗为)、

阿里云技术专家程聪(清音)

责编 | 屠敏

头图 | CSDN 下载自东方 IC

出品 | CSDN（ID：CSDNnews）

长久以来，Linux主机曾一直被认为是比Windows更安全的操作系统，已知病毒形势远没有Windows多样和严重。而近年随着云计算的兴起，Linux系统在云主机的高占比形成了联网主机的主要算力，自然而然地吸引了病毒、黑产的注意力，但对Linux恶意程序攻防的研究仍未达到Windows同等程度，由公众所认识到的Linux恶意程序基本以挖矿程序和DDoS木马为主。

在对云上海量主机文件进行巡检和安全分析过程中发现，尽管考虑到Linux开源生态天然的版本分化因素，Linux的大量基础软件存在超出正常现象的碎片化现象。分析的基础软件包括操作系统基础程序，如ps、kill、netstat等；以及服务类基础应用软件，如Apache httpd、Nginx、OpenSSH。部分软件的版本碎片化呈现日常快速增长趋势，经过分析，其中部分可关联到已知的攻击组织和事件，如DDG挖矿僵尸网络新近被发现存在篡改系统程序植入木马下载器代码；而更多的情况在此前则并未引起注意和披露，也无从解释。随着分析深入，阿里云安全运营中心逐渐发现了围绕污染基础软件展开的多种入侵，而因为基础软件的独特作用，这样的污染往往难以在事中和事后由一般用户进行发现，更难以根除。

为了更好的应对Linux操作系统上独有的安全挑战，2020年以来，阿里云云安全中心专项建设Linux二进制程序恶意样本的发现和分析，通过对云上活跃二进制程序做大数据分析，依靠对可疑程序做多维度打标、大样本量代码相似度与差异聚类比对，形成了一份独有的恶意样本与特征库。其中最典型的一个大类，是对Linux云服务器上搭载的基础软件污染的样本，形成了区别于Windows病毒的一种变种速度快、隐藏方式多、检测难度高的主要威胁形式。以六月份为例，该类别下日均新检测到带有恶意代码的篡改系统二进制程序3840例样本。

本文将从一个典型案例——sshd后门切入，介绍Linux基础软件污染的主要形式，特有威胁，以及查杀关键。

入口之争：从OpenSSHsshd后门谈起

对于入侵行为，sshd作为登录入口，显然很容易被用来当做靶标。如果sshd程序及其配置文件被替换，一方面可以给入侵者留下权限维持的稳定后门，另一方面作为常驻系统的daemon守护进程，sshd中的代码也拥有反复后台执行的机会。因此，围绕篡改sshd的各种后门层出不穷。早期思路，如ssh server wrapper，将sshd功能封装后以脚本替换原始sshd二进制程序，对此有多种方案可以很容易检测。

2018年底，安全公司ESET发布白皮书《The dark side of the ForSSHe》，对其三年期间跟踪的OpenSSH后门进行披露。从Ebury后门开始演进，白皮书共披露了21个后门sshd家族。这些后门在OpenSSH源码基础上，将后门代码以补丁形式植入并编译，从而了无痕迹地得到植入特权登录的硬编码账号、能够窃取合法登录账密的sshd版本用于替换。近几年，这种方案也有一定范围的流传，如采用公开的后门补丁代码模板，可以很方便的进行后门定制。

在云上，通过对全量/usr/sbin/sshd程序文件进行全量的比对分析发现，这一种简单的后门思路衍生出了大量的变形和花式，且在入侵当中发挥了精心设计的作用。

▐ sshd后门脆弱点地图

sshd后门的最基本功能有两项，即针对登录请求的用户校验过程，植入硬编码的账户密码用于绕过校验实现特权免密登录，以及将合法登录请求的账密进行记录或直接回传。因此对sshd程序样本的分析，首要关键点是定位用户校验相关函数，检查是否存在可疑新增代码或过程调用。

在OpenSSH中，支持如下的用户校验机制：

userauth_jpake J-PAKE授权协议userauth_hostbased 基于主机互信userauth_kbdint 键盘交互式userauth_pubkey 公钥机制userauth_passwd 密码userauth_none 无校验userauth_gssapi GSSAPI

而每种校验机制的实现，又涉及较复杂的过程调用链路和支撑的数据构造。仅以密码校验为例，下列函数处在校验链路及分支中，因此都可能在代码层面运行时拿到明文的账号密码，造成数据篡改和外泄：

userauth_passwdmm_auth_passwordauth_passwordsys_auth_passwdsshpam_auth_passwdauth_krb5_password

虽然已有公开信息的原始sshd后门仅针对密码校验的auth_passwd函数，但在对活跃样本梳理后发现，在野恶意版本的恶意代码植入位置选择，已经涉及到了以上多种校验方法的几乎所有关联函数。以下仅针对密码校验相关后门的花式实现做典型实例说明。

▐ 典型sshd后门实现示例

后门连环：userauth_passwd、auth_password、sys_auth_passwd植入点案例

这是三个具有调用关系的函数。userauth_password为外层接口，用于判断当前请求是否为密码更改，因此会提取用户请求中的密码明文，为特权登录密码植入留下机会。该函数的原始代码与后门伪代码如下：

而下一级会调用到auth_password函数，这里会无差别提取请求中的明文密码，并由配置判断分派，是否由系统KRB5（Kerberos）、PAM（Pluggable Authentication Module）还是原始账密方式执行校验。这里的后门实现一般同时包含了特权密码植入和合法账密窃取落盘：

而再下一级到sys_auth_passwd中，在正常的密码加盐哈希校验之前，同样也有后门实现直接进行明文密码比对，如下：

对抗分析：多种后门的免杀实现

针对上述后门实现，人工判断做后门判断以及特征提取匹配也是相对简单的。在避免使用加壳等全局代码混淆方式（这样一来更容易通过文件可疑点圈定样本）的前提下，现已发现多种朴素的免杀实现。

首先是静态字符串的混淆，通过逐字节赋值避免引入字符串常量数据，规避特征串匹配：

其次，针对人工分析中，需要根据函数代码逻辑与交叉引用指纹定位敏感函数的情况，对简单的auth_password做大范围代码改动和插入使其“面目全非”，规避人工审计：

再次，根据ESET等外部披露的后门均将窃取的合法账号密码以固定格式化字符串记录到本地的特征，转为采用在代码中直接命令外传账密的方法，规避基于格式化字符串作为特征的静态扫描检测：

稍微复杂一点的实现

Linux上的恶意程序广泛采用rootkit对恶意代码和行为进行隐藏；而sshd虽然采用无独立程序文件、无新增网络行为方式，但为了规避检测审计和后续入侵行为，下面的后门实例采用完全不同的实现：将窃取账密的功能有独立程序实现并内嵌在sshd母体中释放，同时为了隐藏该模块，额外释放安装一个内核态通用rootkit。同时为了保证这些负载释放过程隐蔽可执行，将植入过程实现在了server_accept_loop消息循环中：

当然，以上仅分析了sshd常规的后门花式实现，但植入少量代码可以实现的后门行为空间本身非常大。现已发现同样有零散案例，后门不仅限于窃取系统账密凭证数据，如下例子实现了对其它应用敏感信息的检索外泄：

▐ sshd后门攻击特征和发展趋势

2020年阿里云云安全中心开展对Linux基础软件的专项治理，其中以sshd后门为切入点，对主流后门做了分析和检测支持。截至2020.07.10，上半年已检测的数据如下：

从数据中，可以解读到如下信息：

活跃的攻击样本变化迅速，而传统安全软件检测滞后。因为根据开源项目和开源攻击负载进行开发，可供选择的定制灵活度极大，所以依赖于传统的样本分析和特征匹配方案，要做到即时检测响应，难度很大。ESET在2018年底发布白皮书披露的21个OpenSSH后门家族特征，在2020年内已经不再有匹配的新增样本；而根据植入后门的恶意负载的信息收集方式/路径/特征串、植入特权账密进行聚类，半年间发现56个高度疑似有组织的新增植入源。在此情况下，完全结合云主机的安全解决方案，因为能够实时掌握新增样本的特征和趋势，所以在准实时检测方面具有先天优势。
以sshd后门做持久化攻击具有极高定向性，且真实影响范围远大于直接影响。从样本维度看，虽然检出样本中，存在感染100个以上ECS实例这样的“通用”样本，但绝大多数样本仅定向投放，至多污染5个实例；这种样本使用上的“不经济”做法，能够有效避免引起注意而被杀，同时分散审计、检测者的精力，主要也是得益于能够快速、批量生成大量样本的特性。而从用户维度看，绝大多数的用户，仅有1个实例被植入后门，受影响用户的机器后门污染率仅0.59%；这并不说明影响范围受限，恰恰相反，投放上疑似有意识的克制，在行动中规避了受害用户自己的察觉，从结果看，因为同个用户的批量ECS实例有较高可能共用账户密码，所以在仅有1个实例存在窃密后门情况下，其余实例也就处在无痕迹入侵的威胁中，这个威胁的影响面比直接告警后门的机器数，预估为170倍以上；同时，也有发现部分客户的登录跳板机sshd出现后门替换痕迹，这更放大了实际威胁程度。
sshd后门的出现与已知模式的入侵行为有很高相关性。阿里云云安全中心具备对业界已知的各类入侵行为的检测、防御能力。从后门检测和入侵的关联来看，18.2%实例的后门植入有前置已知入侵历史，此时后门的作用是权限维持；26.2%实例随后门植入有后置入侵动作，此时后门则作为攻击入口的抢滩；大量实例在发现后门sshd样本之前，已经存在历史残留的rootkit用于隐藏入侵痕迹，其中存在多种针对性隐藏sshd后门网络行为和文件的rootkit。可见，sshd后门的使用和作用并不单一。而从影响看，大量后门的告警出现在规模较高的大客户范围内，大客户在受害用户中占比很高，且存在目标行业选择性，因此不能简单将sshd后门视作一般意义上的病毒，而应联系到其上下游，关联各类型异常做攻击事件定性分析。

Linux基础软件威胁疑云：从已知到“未知”

上述以OpenSSH为例，揭示了针对Linux开源基础软件，一个公开的恶意代码植入思路可能演化出的多样形式。由此切入，我们再来探讨Linux开源程序面临的威胁全景。

▐ 已知：基础软件污染事件

OpenSSH被选择作为后门载体，一方面由于其本身是登录入口程序，具有功能敏感性；另一方面由于作为Linux系统的daemon程序之一，具有常驻后台的特性。实际上，Linux的基础软件，包括操作系统基本功能的基础程序，以及Linux服务器主机常用的服务程序，都由于以上两个特性之一，存在已知或未曾披露过的污染。

Linux操作系统基础程序：病毒持久化温床

Linux由于系统设计理念，存在大量系统原子功能设计为基础程序（如ls、ps、grep等），大量与系统的交互功能由这些基础程序的调用串接完成，因此这些基础软件总是不可避免地得以高频调用。另一些系统程序，类似sshd，是默认后台执行的daemon看守程序，涉及底层系统管理、监控、服务提供等功能。因此这些程序天然的成为恶意代码持久化运行的目标载体。

在DDG僵尸网络中，多种入侵和感染方式结合用于确保挖矿任务的成功下发、维持和隐藏。在最新的样本分析中，阿里云安全运营中心发现在过往的入侵行为中，存在将多例系统基础程序进行替换的历史。被替换的基础程序涉及grep，awk，sendmail，chattr，pkill，lsattr，sleep，wget等。为保证恶意程序本身简洁且高度兼容，这些用于替换的程序没有选择在独立的源码基础上进行修改（即，替换版本的pkill并非原版的pgrep/pkill源码编译），而是统一采用busybox源码插入后门代码，编译后的二进制程序替换到目标系统路径后，由main调用到DDG的木马代码，如下图。与此类似，近期也新定位到一类新增的系统程序替换污染，将若干系统程序替换为由glibc源码中加入了恶意main代码之后编译的二进制程序。

另一部分具有“入口”性质的Linux系统基础程序，也存在广泛的感染风险威胁。现已观察到，agetty、dhclient、bash、sftp-server、sudo、login、irqbalance、gssproxy、anacron等代码版本长期稳定的系统程序，存在频繁的更新、挪移操作；而对于Linux系统服务的daemon程序，也是入侵中的篡改、后门植入的敏感领域；在近两年，阿里云安全运营中心已经发现有包括如下系统daemon存在可疑文件变动：dbus-daemon，systemd-logind，systemd-journald，auditd，ntpd，rsyslogd，chronyd，lvmetad，atd，rpc.statd，packagekitd，xinetd，vsftpd，等等。针对以上可疑的文件挪移、篡改，阿里云云安全中心已经具有监测告警的模型，预警用户进行审计；对于样本的恶意代码分析检测，也已经具有大量沉淀，且在逐步覆盖对可疑事件中的样本的判别能力。

后台服务类基础应用软件：业务/数据驱动型威胁新目标

除了系统基础程序外，一些第三方开源基础应用软件，更是存在非常多种供应链来源、频繁的版本更迭，在一般用户业务中起主要业务应用角色的程序包，直接处理业务逻辑、用户数据，是关键敏感程序。这些应用的安全性更直接关乎业务而非主机的安全性。

Linux云主机搭载的最主流应用为Apache httpd和Nginx。如2013年曾经由ESET和Sucuri披露的Linux/Cdorked.A反连后门，即是插入了恶意代码编译的httpd daemon程序，其后门实现与原始代码功能逻辑结合，在http请求头的复杂处理分支中埋下新增的控制命令处理，用于条件触发植入的反弹shell模块等后门功能，并增加请求重定向以实现隐藏。这个后门因为不通过此前广泛传播的配置文件修改、新增后门扩展模块的方式实现，且没有其它文件落盘、消除日志，所以一旦完成了植入，或者通过安装过程污染，则仅能通过对httpd程序文件的特征检测才能发现。这类家族同时还覆盖了Nginx、Lighttpd，可见在服务应用软件二进制层面的后门隐藏，是早已开始的一个对抗战场。

▐ “未知”：从数据窥见威胁

由于先天的开源生态，相较于Windows软件大多以二进制形式发布，Linux有大量程序为源码形式为用户自行拉取、定制、编译使用，或从其它渠道下载预编译二进制版本。由此引入了大量的版本碎片化现象，主要体现在三方面：

由编译过程引入的特异性差异。不同的编译环境与配置，不止会在编译后二进制中留下指纹，也包括了build-id这样的先天差异；更重要的是跨编译器和版本情况下，代码生成策略不同带来的一般差异。
由代码定制引入的奇异版本。出于业务和功能需求，在开源代码上引入增量代码，会产生一个“小众”版本。对于独立审计的第三方而言，判断出增量代码是首要难点，而判断增量代码是否“善良”则是更大挑战。
由多样的软件供应链路引入的碎片化。Linux应用往往具有依赖繁复的特性，为此对一些通用场景，存在大量第三方提供预编译的软件打包，如仅仅pure-ftpd程序，就被包含在lanmp、phpstudy、EZHTTP、wdlinux等多种web服务器应用打包方案中提供，从而引入额外的碎片化，其中包括下载途径等部分供应链也并不可信，甚至存在历史问题。

而即便在考虑了以上所有白色、灰色的版本碎片化之外，通过数据分析，阿里云安全运营中心也可观察到了部分程序在全量主机上，出现了高度可疑的严重碎片化现状和趋势。其中有代表性数据如下：

在这份数据中，抽样采集了Linux主要程序的碎片化分布。上图选取了碎片化较多和较正常的部分daemon类程序数据；作为对照，如auditd、atd等代码简单且近几年无代码变更的系统daemon程序，日活md5版本数约在100上下，而其余版本数量居于前列的daemon则表现出偏离正常版本数的趋势。而下图则统计了各类常见应用的碎片化，除了curl、rpm、chmod等已知病毒做污染的常见目标程序外，Nginx、httpd的碎片化趋势显然超出了正常区间；部分基础软件月均新增版本超过5000，构成了碎片化潜在威胁中的重点关注目标。

根据前文披露的sshd后门检测阶段结果可知，常见程序的低安装量的版本往往直接预示着高度可疑，而从整体来看，这种低安装量、存在周期性迭代替换的“奇异”版本的大量存在和增长，即是当前面临的基础软件威胁表征。同时，版本碎片化增长数量又呈现出与攻击事件时间热度相关的趋势，也佐证了基础软件污染已成为在野入侵事件组成成分。

对抗方案：从单机审计到数据判别

▐ 样本分析审计的难点

针对已知类型、攻击思路和可疑代码目标位置的恶意程序，如果需要在单机上进行审计，排查是否中招，将面临以下困难：

二进制无符号，相关函数没有特征可定位。例如OpenSSH的auth相关函数，并没有特征常量字符串定位，同时又由于不同配置下的条件编译，导致二进制代码也没有统一特征或调用关系，所以很难在反编译函数中定位到目标。
多数开源项目固有版本多、差异大，包括大小版本、发行版back port版本，需要跨差异进行比对、做函数差异分析需要完备的跨版本特征储备。如rhel版本相比上游原始OpenSSH release的同版本号版本即有一定差异。
后门的实现可能并不会引入具有特征的代码，甚至可能只是代码层面的微小变动。此时，就需要对载体代码原本的功能逻辑和潜在脆弱点具备了解。但同时，对目标有选择地审计也会造成盲区，因此全量代码比对存在必要。
持久化代码一般为独立函数、隐藏调用链，而比对发现非特定版本的二进制增量代码，在没有基于语义解析的自动化工具辅助下，需要大量人工分析投入。
成熟的攻击样本基本配备完备的隐藏方案。例如，后门程序往往篡改了rpm配置文件，使得rpm -Va做rpm包校验无效；或消除了各类日志以避免通过行为异常发现。

▐ 云上大数据判别

虽然个人用户很难判定自己主机的文件是否已经被替换为恶意版本，但是攻击事件往往不是孤立稀疏的，因此作为阿里云安全运营中心，就具备站在更高维度监控异动的可能。

阿里云的云安全中心目前具有对云上新增二进制程序样本的自动分析能力，针对集中或规律性出现、存在大量碎片化的Linux基础软件，从数据层面做趋势监控，并基于代码语义层面的相似度聚类，快速定位并辅助专家分析差异代码，圈定潜在恶意版本。在3月以来，云安全中心的云查杀模块，上线了“被污染的基础软件”这一个新的告警类别，将上述所有Linux基础软件的污染、后门篡改统一告警，引导用户进行复核和修复。对于大数据监控与自动化分析的方案，将在后续文章进行单独介绍。

▐ 用户防护建议

虽然基础软件篡改类型的恶意样本与入侵往往较为严密，在攻击成本和个人用户发现难度之间存在杠杆，但一般用户仍然可以从以下方面尝试被动发现和主动防护：

应用文件篡改和奇异样本分析。可以从主要系统基础程序的时间戳、rpm校验信息等方面入手，排查是否有较为简单的文件替换；如果有多个同配置主机实例，可以做文件比对，发现差异。对于阿里云云安全中心用户，可以重点关注“篡改系统文件”和“被污染的基础软件”两种类型的告警，分别从行为和样本维度对上述分析实现自动化呈现。
积极处理各类异常告警并修复漏洞。虽然基础软件污染难以做事后发现，但其自身并不构成完整攻击，总是和其它入侵事件配合。因此用户需要对于各类告警做通盘考虑，修复告警的漏洞，确保告警的各类病毒、webshell等的清理结果，筛查分析各种可疑事件告警。
保证使用第三方软件来源可信。软件供应链污染是新兴但并无充分曝光信息的低成本攻击方式，攻击者可能通过各种不可信的渠道从上游污染用户代码，潜在包括恶意的预编译软件包下载源、小众无透明可验证信息的rpm源、个人或非正式渠道发布的系统装机镜像或docker镜像，等等。以上需要用户自行进行安全性保证。